Use Case Maps for Attributing Behaviour to System Architecture

The ability to attribute behaviour to architecture is important for high-level understanding, designing, evolving, and reengineering all kinds of systems (from objectoriented programs to parallel and distributed computer systems). Scenarios are a good way of doing it, but popular scenario techniques, such as message sequence charts, that use intercomponent “wiring” as their starting point do not scale up well. Use case maps provide a new, scenario-based way of attributing behaviour to architecture that solves the scaleup problem. The notation enables compact, composite maps to be drawn to represent behaviour patterns of whole systems in terms of causal paths, without reference to “wiring”. Through an example, the paper aims to convince software and system engineers that the approach has depth and adds value, despite (and because of) its simplicity and deferment of detail. 1.0 Complexity Factors in Systems Systems are often characterized at a high level of abstraction by block diagrams such as the following (called here component context diagrams), in which the boxes represent collaborating components, every one of which is potentially—through recursive decomposition—itself a system. To attribute behaviour to systems described with component context diagrams, connective tissue must be added. One form of connective tissue is intercomponent wires, meaning conceptual or actual connections that support interactions—such as calls or messages— between components through interfaces (a component context diagram with wires is called a wiring). Wirings are assumed to identify explicitly the names and parameters of all possible interactions, without reference to the internal logic of components. Behaviour may be attributed to wirings by describing interaction scenarios with interaction diagrams [7] (which we shall henceforth refer to by the generic term message sequence charts). We argue below that the combination of wirings and message sequence charts will overwhelm us with detail for systems of any size or complexity. We need to stand back from such detail to see the big picture clearly, in other words to see the system in architectural terms. Furthermore, wirings that are concrete enough to be useful for understanding behaviour in the above terms are too detailed to be considered as architecture diagrams unless systems are one-off, small, and simple. For families of large or complex systems, architecture should have more to do with rules or guidelines for creating concrete wirings over the family than with the specifics of individual wirings. Diagrams showing only the existence of relationships such as uses, communicates with, or has contract with are useful for architecture, but they are not wirings in the terms of this paper, and are therefore not starting points for attributing behaviour to architecture. Now let us examine the complexity factors associated with wirings and message sequence charts that will cause us to be overwhelmed with detail. They fall under three headings: operation, assembly, and manufacturing. Operation. Wirings provide a means of understanding the operation of a system in terms of interactions over wires between components. Wirings must include wires not only between peer components at operation described in terms of interactions over wires the same level of recursive decomposition but also between components at different levels of recursive decomposition, through all levels of decomposition (symbolized by the arrows in the figure, remembering that there would be many more arrows in actual wirings). Such wirings give us a view of system operation in terms of compositions of many details, tending to overwhelm the big picture with details. The effect is compounded by two other factors. Assembly. Systems may change form while they are running, in other words, they may be structurally dynamic (why we associate the term assembly with this will be explained shortly). Structural dynamics is a routine property of systems and software, not an unusual one. When systems are viewed in terms of wiring diagrams as above, structural dynamics means that both the components and the wiring may change over time (symbolized in the following diagram by a sequence of snapshots, each of which show different components and different wiring at different times). We say that the wiring in each snapshot shows connections that enable operation, that sequences of snapshots imply assembly (meaning that new components and wiring must be assembled in between snapshots), and that operation + assembly = behaviour. Even without any specific description of how assembly is to be accomplished in between the snapshots, viewing assembly in terms of changing wirings obviously adds complexity to an already complex picture. This complexity seems counterintuitive, considering the lightweight way in which assembly happens in code (pointers are assigned for new software components and passed around to other components). Manufacturing. The third complexity factor is that behaviour (in the above sense of operation+assembly) becomes intertwined with manufacturing (in the sense of manufacturing objects from inheritance relationships in class hierarchies). This is symbolized in the following figure by showing a class hierarchy on the right from which the operational snapshot